Hello Forum,

Does MS Access 2013 support encrypted remote client connections?  If so, how?  IPv6 required?

thanks

Hello Forum,

Does Access 2013 support multiple simultaneous connections? If so, how is data integrity maintained?

Does Access 2013 support encrypted remote client connections?  If so, how?  IPv6?

thanks

Access supports multiple connections. However a better term is such a database supports multiple clients who open the database.

Remember, Word, or Excel or Access are simply file based systems. You dont connect to word, or power-point or Access.

You OPEN the file. So any connection string say via ODBC will ALWAYS resolve to a standard windows file location. This means for example you cannot connect to an Access database over the internet unless you extend the windows file and networking system OVER the internet to that target location. (so the target location MUST support windows standard file opening and connections a file placed on say a remote web server does NOT support clients directly opening files from the client side).

Concurrency, and transactions in Access databases are supported. This is achieved by two things:

#1
The windows file system (which you MUST use to open the database) supports file locking. (windows op-locks). This also explains why often the back end database cannot be placed on a network storage system as opposed to a windows server.

#2
When you open the access file (again, I stress the word open as opposed to connection), then a locking file is created and placed in the same location as the database file (typically a accDB file). So both the windows file locking system, and that of Access databases creating a temporary locking file to manage concurrency, transactions and collisions is created.

So it is MOST important to grasp the difference between a file based system like Access, and that of database server or better term service that you connect to. You connect to a database server, but you open Access files a major difference.

As for encrypted connections, as I pointed out that does not make sense in this context. We open a word file, we open a excel file, or we open an Access accDB data file. So the use of the term connection is a less then ideal term here in this context. Note that it is the client side software that opens the Access file regardless of where the target file is located.

So you cannot use a socket tc/ip connection to Access, you must use something that extends the Access file system OVER that tc/ip connection. (so you need windows file networking system to be supported OVER that tc/ip connection).

You can thus setup a VPN connection that extends the windows networking system over the internet, and that VPN networking connection can be encrypted, but that is a transport system and networking layer above Access that Access does not see nor care about.

So the higher level networking connection can be encrypted, but from any office program like Word, or Excel or Access we talking about a plane Jane windows file open occurring here. The fact that the windows networking system is encrypted is not seen nor does Power-Point or Word or Access care or know about. (again, just a plain Jane file open of a file sitting on the hard drive is occurring here).

There are certainly setups with Access that can use socket based connections, such as using Access as the front end development tool and then using linked tables to SQL server.

So the term Access can be confusing, since you have a choice as to the type of back end database. Access is NOT just a database, but in fact a whole development tool. It lets you built forms etc. (something that SQL server does not do for example). So Access has two parts:

The form + coding and development part
The default Access database called JET (now called ACE).

If you used the built in Database engine with Access (called ACE or JET), then this is as per above a file open command based on standard windows file open and networking. If you use a back end database like Oracle, or SQL server, then encrypted connections can be utilized, but as noted in most cases this is the choice of the network security, and not that of an Access front end connecting to a back end.

As for using Access over the intent, I explain the difference between a LAN and WAN here:

http://www.kallal.ca//Wan/Wans.html

So you cannot connect to a Access database simply with tc/ip, you need the windows networking system to be passed OVER that network connection to allow standard windows file open commands on the Access data file.

Regards,
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

I am going to add a short follow up, since this post has been moved to office 365.

Access can store the back end data in the cloud (office 365). You can then deploy the application part to desktops, and any desktop with an internet connection can (and will) be sharing the same back end database.

Access has two choices that work with 365.

Push the tables up to SharePoint lists. This choice does support relations between tables. (works well with Access 2010, or 2013 and office 365 on-line)

Publish the Access database (2013) as web based to 365. This choice creates behind the scenes a SQL Azure database of which then you can link the Access front end(s) deployed to any computer and data is shared as long as they have an internet connection.

So while your question was in the context of a Access file back end, office 365 offers several choices that allows one to store the table data in the on-line part of 365, but lets you continue using Access as the front end part to the data residing on 365.

So the context of the question is much important here, since my previous long answer assumed an Access back end file along with its limitations.

However you dont have to use/choose such an Access back end when using Access with office 365.

You have options and choices to place the data in office 365 which then can be directly edited and consumed by any computer with Access desktop or even the free Access runtime. This setup is encrypted, and you only need a socket (TC/IP) connection to the internet for this to work.

Regards,
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada